Geographic Filter For Regulating Inbound and Outbound Network Communications

ABSTRACT

A system and method for regulating and analyzing inbound and outbound communications in and between computer networks on the basis of geographic security assertions are provided. Geographic information is collected, optimized, and shared between network objects to enforce network access control on the basis of configurable security assertions. Security assertions are configured and metrics displayed using maps and other geographic data in a graphical user interface.

RELATED APPLICATIONS

This application is a divisional application of and claims the benefitof priority to U.S. patent application Ser. No. 14/077,116, filed Nov.11, 2013, currently co-pending, which claims the benefit of priority toU.S. patent application Ser. No. 11/698,624, filed Jan. 26, 2007, nowU.S. Pat. No. 8,584,226, which claims priority to U.S. ProvisionalApplication No. 60/762,482 filed on Jan. 26, 2006, all of which arehereby incorporated fully herein by reference into this application.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the art of utilizing geographicinformation as a basis for network access control, specifically, theextraction and analysis of IP protocol attributes for the plurality ofpackets traversing a data network, resulting in real-time classificationof said packets in a manner that facilitates responses based on a set ofpre-defined, geographic, security assertions.

2. Background of the Invention

The firewall has long been the de facto standard of network perimeterdefense, guarding computer resources from unauthorized access byregulating the transmission of data packets to protected devicesaccording to a rule-set. Presently, most network firewalls perform adiverse range of functions, including Network Address Translation (NAT),support for virtual private networking (VPN), stateful TCP/IP connectiontracking, as well as, other sophisticated techniques of analyzing packetand protocol characteristics. One example of such a device isCheckpoint's Firewall-1, a product described by U.S. Pat. Nos.5,606,668, 5,835,726, 6,496,935, 6,873,988, and 6,850,943.

Generically, firewalls operate primarily by analyzing network trafficusing a pre-defined set of rules that determine how data packets areprocessed. One limitation of firewalls is that their operation isdependent upon the information contained within networking protocols.Information external to a protocol, information not contained within thesyntactic construction of a data packet of a specific protocol type,presents a challenge to firewall technology in relation to that protocolin the form of a blind spot. This blind spot constitutes a set ofunknowns, various information states that the firewall cannot observe ormeasure, but must either infer through some mechanism or obtain viainteroperation with another device or devices with different views ofthe network or the given protocol. It should be noted that this problemis not unique to firewalls, but is also affects Intrusion DetectionSystems (IDS) and Intrusion Prevention Systems (IPS) systems, a weaknesssystematically documented in Ptacek and Newsham's classic paper,“Insertion, Evasion, and Denial of Service.”

This fundamental limitation has led to the development of diversefirewall technologies in recent years. This technological growth can becharacterized, broadly, as following two lines of development, each lineaddressing the basic “blind spot” limitation through a differenttechnological track.

One line of development has focused on improving the firewall's abilityto decode, analyze, and track the state of information passing betweencomputer systems on a data network. This type of technology is oftenreferred to as a stateful packet-filter. One example of technologicalinnovation in the area of protocol processing is Checkpoint's U.S. Pat.No. 5,606,668, facilitating the stateful inspection of TCP/IP segments.This technology addresses the blind spot problem by allowing thefirewall to better maintain state between machines communicating throughthe firewall and by accurately tracking the connection state betweensystems traversing the firewall.

Checkpoint's Stateful Inspection technology, while a fundamentalinnovation in the field, addresses the blind spot problem only in part.The position of a device on a network and the information available fromits localized point of processing introduces a fundamental myopia thateven perfect protocol analysis and session state tracking cannoteliminate. This has led to a second line of evolution within firewalltechnologies, the development of new species of firewalls designed toaddress a different dimension of their limitations. This diversificationof firewall technology includes Host-based “personal” firewalls,application-layer firewalls, and specialized proxy-firewalls, to give afew examples.

Despite the proliferation of firewall and hybrid IDS/IPS technologiesand the protection that these technologies provide there exists a needto regulate network access control for IP networks on the basis of thegeographic location of network entities. The inability to preemptivelyblock or otherwise respond to network data packets in real time on thebasis of geographic location has been a longstanding limitation offirewall technology. Since the information necessary for determining thegeographic location of a datagram or TCP segment is, principally,meta-information external to IP-based protocols, this type of accesscontrol has its own unique challenges.

Since the turn of the century, numerous geographic-based IP technologieshave emerged, some specifically related to firewalls and access control.One example of a geographically aware firewall technology is describedby U.S. Pat. No. 6,839,852, owned by McAfee. This technology is ahost-based firewall program described as capable of retroactivelytracing the geographic origin of a network event logged by the firewall.However, it does not block inbound or outbound network traffic based ongeographic factors and thus still suffers from the same geographicblindness as predecessor technologies.

With the McAfee exception, patented geographic technologies seem to havebeen mostly developed over the last few years, largely to meet marketdemands in the area of advertising and marketing, but with interestgrowing in the application of Internet Geolocation technology to networkand application security. A number of patents have been granted toInternet Geolocation companies, most prominently: Digital Envoy, Inc,U.S. Pat. No. 6,757,740, Quova, Inc., U.S. Pat. No. 7,072,963 and U.S.Pat. No. 6,684,250, IBM Inc., U.S. Pat. No. 7,100,204, inventor CyrilHouri, U.S. Pat. No. 6,665,715, and US patent application 20060206624,concerning a technology for determining the geographic location of webresources. Recently, the NSA was also granted a patent related todetermining the geographic location of a networked entity, described byU.S. Pat. No. 6,947,978.

Additionally, many companies currently license Internet Geolocationdatabases containing mappings between IP addresses and geographicinformation at various degrees of granularity. The application ofgeolocation technologies to the field of computer and data networksecurity is occurring both commercially and, at a grass-roots level,with the commercial technologies primarily focused on geolocation at theApplication-Layer (OSI Model Layer 7) focused mainly to combat thewidespread phenomena of Identity Theft and Internet fraud. At thegrassroots level, various individuals, organizations, and projects areusing geographic information in creative ways, such as D-Shield(www.dshield.org), which utilizes firewall logs voluntarily uploaded byusers to create a global picture of network attack patterns and trends.Other individuals and organizations have authored scripts and tools forconverting geographic databases and information from Regional InternetRegistrars (RIRs) into firewall rules, with notable work being done forthe Linux firewall netfilter.

Efforts to adapt existing firewall and Access Control List (ACL)technologies, like routers, to the challenges of enforcinggeographic-based rules use a number of techniques, most with seriousdisadvantages. Conventionally, these approaches have involved atime-consuming manual processes, carried out on a piece-meal basis. Forexample, creating geographic rules for a firewall typically involvesusing or writing a Perl script to parse a list, or using an existingdatabase by importing its contents into a SQL-based database, and thenusing SQL queries to generate firewall rules for the desired regions orcountries. These rules are then imported or added into the firewallrule-set or used for modifying SMTP server configurations to reject mailfrom particular geographic areas. Such processes are time consuming dueto the need for precise syntax within the constructed rules, and overallinvolve a lot of line-by-line proofing or fluency with the use ofUnix/Linux regular expressions, as well as, a scripting language,commonly Perl.

Second, existing firewall technologies are largely unsuited for usingcomplete geographic rule-sets, such as a rule set constructed from a RIRdelegated list or created from a geographic database, as such rule setscan easily comprise over 100,000 rules. Utilization of geographic ruleswithin firewall or router technologies is only efficiently implementedon a very selective basis due to the information processing demands ofvery large rule sets. This problem is further exacerbated withinenterprise networks that operate at gigabit speeds. As a result, thefull benefits of geographic protection are never realized.

Implementing an exhaustive and regimented policy of geographic accesscontrol for even a single network device is highly impractical usingexisting firewall technologies. These performance limitations, coupledwith the highly manual volume of administration required to update andmaintain a large cumbersome rule-set presently excludes most enterprisenetworks from realizing the benefits of geographic security controlsenforced via access control technology. Due to the limitations inexisting technologies to provide effective geographic based networkaccess control we decided to approach the problem area in a differentway abandoning the limitations of the firewall and its kin.

We refer to this new technology, as Geographic Threat Protection, orGTP. This technology offers significant benefits for any networkprotected by a GTP service or device in terms of enhanced defense indepth for network security. Another example of the technology wouldallow companies to enforce network access control policies where trafficfrom only the countries they do business with would be allowed. Thus,bandwidth can be saved by blocking unwanted network traffic fromcountries the company doesn't do business with, in addition, to themultiple security benefits of such a technology.

The creation of GTP technology was driven by events, both recent andhistorical, and by a realization of vulnerability inherent in theInternet on which both business and government increasingly depend: fromPerl Harbor to 9/11, the United States has occasionally been blindsidedby an enemy which strikes without warning. Geographic Threat Protectionis a sound defensive measure to prevent sudden and devastating attacksagainst U.S. companies and US critical infrastructure from the Internet.

We believe that geographic threat protection will make the United Statesand its corporate and government networks more defensible, lessvulnerable to Internet-Based threats. Today's Internet is thefulfillment of the grand dream of open networks, of a world in which acomputer in South Africa, or a Pakistan, North Korea, or Poland cancommunicate with a network in West Texas: any node can exchangeinformation with any other node, seamlessly. What has becomeincreasingly evident over time is that the lack of geographic securitycontrols means any Internet-enabled system is exposed, surrounded,seated in an electronic world without borders, terrain, or obstacles.This is perhaps the strictest definition of an indefensible position.While Firewalls can protect a network from outside access, they cannotregulate such activity on the scale of geographic regions as is donewith GTP. Nuclear power, electrical plants, petroleum refining, massproduction, commerce, and e-commerce all rely upon a network ofinterconnected systems in which any node on the network is adjacent. AnInternet enabled network is perpetually surrounded, with only thefirewall and intrusion prevention system to forestall attack, and these,lack any a priori visibility of the geographic origin of incomingattacks. With geographic knowledge, the vast majority of internet-basedattacks can be blocked before they occur. In the latest Internet ThreatReport from Symantec, over 70% of attacks detected came from non-US IPaddresses, thus, one can see the potential security benefits possiblewith blocking traffic based on country of origin.

SUMMARY OF THE INVENTION

The invention provides a special type of packet filter suited as afirewall for the Internet Protocol versions 4 and 6, as well as,encapsulated protocols, based on geographic location data using apre-configured rule-set. Specifically, a method and apparatus isdescribed for a “geographic filter” that either directly processes orindirectly facilitates the processing thereof a plurality of datapackets, and enables the use of specified actions against the individualpackets comprising the plurality of packets based on a user configurablerule set in which geographic identifiers are paired with device actions.

The packet filter monitors network traffic and extracts information fromeach datagram or segment traversing a network link, then analyzes thisinformation in real-time by parsing the packet or segment accordinglyand referencing the parsed information within a memory structurespecifically designed for holding geographic, and related, data. Adevice action, informally a routing or logging decision, is made withregard to each datagram on the basis of high-level rules that relate tothe contents of the memory structure (i.e. the geographic classificationengine) in a generic manner.

Ordinary firewalls consist of low-level rules central to the operationof the device, and thus constructing these rules on the basis ofavailable geographic mappings between IP addresses and geographiclocations requires thousands of rules due to the large number of addressranges or CIDR blocks involved in such a mapping. Additionally,traditional firewalls receive incoming protocol traffic, then decode andanalyze this traffic, and the analyzed attributes of the datagram arecompared to the device rule-set in a manner that approximates sequentialor line-by-line comparison. A traditional firewall without explicitrules blocks nothing.

The advantage of this architecture is that the device requires very fewrules, and those rules that are required are relatively simplistic.Access control by the geographic filter is performed by an engineseparate from the rules themselves. Thus the device is preconfigured, atwhich point the rules cease to be of actionable importance and do notthemselves factor into access control activities. Once configured, thedevice does not rely on rules in the ordinary sense, but rather, aspecialized memory structure similar to a routing table, which containsall the necessary information determining the appropriate action to takeupon the datagram or segment.

According to one aspect of the invention is a method of blocking,allowing, logging, or redirecting TCP/IP network traffic on the basis ofan abstract rule-set used during the configuration of a geographicclassification engine. The method consists of a packet filter designedto respond to the directives of a memory structure maintaining tablemappings of the IP protocol address space. The computation involves theanalysis of an IP address and possibly the permutation of an IP addressinto another entity such as a 32 bit integer or via association with adatabase of related information. Abstractly, the IP address is onepossible value of a resource identifier, and the lookup or comparison ofthe resource identifier value to the contents of a memory structureresults in access control decisions by the device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an example of a geographic filter device;

FIG. 2 shows a base formal translation within a geographic securityassertion;

FIG. 3, shows an example geographic filter device performing a deviceaction within a basic geographical topology;

FIG. 4 demonstrates unique parsing mechanisms within a specialized inputprocessing engine;

FIG. 5, shows a composition of a configuration post-processing engine;

FIG. 6, shows a composition of a transcoding-parsing engine;

FIG. 7, explains a composition of a functional input engine;

FIG. 8, shows a composition and explains the process of a geographicfilter engine;

FIG. 9, shows a composition of a network filtering engine;

FIG. 10, shows a composition of a transcoding-output engine; and

FIG. 11, shows a composition of a reporting engine.

DETAILED DESCRIPTION

A detailed description is provided for a geographic filter device thatimplements processes of analyzing and conditionally responding on thebasis of geographic associations of inbound and outbound networkcommunications. The geographic filter device consists of a set ofengines and modules which internalize functions for the following:

A set of configuration functions relating to input, input optimization,and communication of processed configuration directives to otherfunctional groups, comprising: a means for receiving input from a userinterface, and a means for optimizing said input by converting theconfiguration information into generic device instructions, a means ofextracting configuration information or stored state information from afunctional module exported to a storage media or transmitted betweennetworked nodes, and outputting processed input to other functionalgroups. A set of input parsing and encoding functions for receiving,structuring, and producing output in accordance with three input modesand three output modes, and the programmatic means for switching betweenthe various input and output modes. These and other functions areperformed by the Configuration Post-Processing Engine 404 shown in FIG.4.

A set of functions to prepare a media for parsing utilizing a means ofretrieving from a location, opening, and reading the source media, inaccordance with a media interface function and a media reading function.These and other functions are performed by the Functional Input Engine402 shown in FIG. 4.

A set of functions for processing geographic information by means ofwhich geographic information is stored, categorized, and indexed,enabling a programmatic means for mapping IP addresses to geographicregions and retrieving said mappings or geographic associations relatedto said mappings, on demand, including, a means for analyzing a securityassertion into a set of IP address blocks associated with deviceactions; a means for loading particular IP address blocks into a memorystructure; a means for comparing an IP address provided as input withthe IP addresses stored within a memory structure. These and otherfunctions are carried out by the Geographic Filtering Engine 408 in FIG.4.

A set of functions for interfacing with a network through a networkinterface, including a means for: performing an action on a networkpacket, initiating a response to a network packet, logging actions andresponses in accordance with operational parameters. These and otherfunctions are carried out by the Network Filtering Engine 412 in FIG. 4.

A set of functions for manipulating system output, including: parsingoutput based on operational parameters, writing output to a variety ofmedia types, or outputting information in accordance with a feed orstream in real-time to another network object. These and other functionsare performed by the Transcoding-Output Engine 414 in FIG. 4.

A set of functions whereby system operation is reported to a user orprocess, the format of said reporting including: reporting in a genericformat as determined by operational parameters, reporting information bywriting files to a local or remote file system, reporting to a networkprocess or service, reporting to a database via an ODBC operation. Theseand other functions are performed by the Reporting Engine 416 in FIG. 4.

A set of user interface functions reporting the result of loggingactivities to a user, the operation of said functions involving aGraphical User Interface (GUI) in which Device Action events aredisplayed visually on a map in accordance with user configurablecriteria for the purpose of altering, changing, or establishing deviceconfiguration parameters as relating to reporting activities, includingthe display of said device action events depicted visually in accordancewith spatial and geographic relationships. These and other functions arecarried out by the User Interface Engine 406 in FIG. 4.

Referring now to FIG. 1, an example geographic filter device and a basicgeographical topology is shown. In this example, the four network nodes102, 104, 106, and 108, connect through the geographic filter device 5.Other network objects such as firewalls, routers, switches, VPNs, etc.,may be present, but are not shown. Within the context of the diagram,network nodes 102, 104, 106, and 108, are network nodes protected by thegeographic filter device 110. To be more specific, 102, 104, 106, and108 are network objects, such as subnets, servers, services running onhosts, or any other type of appliance or device capable of communicatinga network. Network objects, 102, 104, 106, and 108 are protected by thegeographic filter device 110 in virtue of the placement or location of110 within the network architecture. Inbound communication fromgeographic region ZA 122 must pass through the geographic filter device110 when transmitting to network objects 102, 104, 106, and 108.Conversely, outbound communication from network objects 102, 104, 106,and 108 must pass through the geographic filter device 110 whichmediates communication with external regions, such as region ZA 122, andregion AO 124. Hence 102, 104, 106, and 108 are protected networkobjects in relation to the geographic filter device 110.

The geographic filter device 110 in FIG. 1 is configured with networkinformation related to defined regions AO 124, NA 128, BW 126, and ZA122. For simplicity, this and future examples, we shall consider regions122, 124, 126, and 128 to constitute the totality of geographic regionsconfigured for the geographic filter device 110. In actualimplementation, the scope and detail of geographic filtering activitymay be as limited as to apply to one subnet within one geographicregion, or as broad to include the entire world.

In FIG. 1, 120 is the information used during the configuration ofgeographic filter device 110. The Information (geographic) 120 can besourced from a variety of sources: a proprietary database, a public listof such information, extracted from HTML documents, or remotelyretrieved from other geographic security devices, etc., however, thecompleteness, accuracy, and timeliness of the information is quiteimportant as the provided information 120 will determine the accuracyand overall effectiveness of device 110. Information 120 is processed bythe geographic filter device 110 when geographic security assertions 8,and 9, are supplied. The geographic security assertions 116, 118 aredefined in relation to the information 120, thus arriving at a low-leveldefinition of the geographic security assertions. One example of alow-level definition or translation of a geographic security assertion116 is to convert “ZA” into a set of IP address blocks or ranges, andthus to apply the defined action “BLOCK” to the range or blocks of IPaddresses constituting the low-level definition of “ZA”. The result ofthe processing is the representation of geographic security assertion116 into a compact form, henceforth, referred to as the compactrepresentation, within the geographic filter device 110, as shown in thediagram above abbreviated as “ZA−”. Conversely, the compactrepresentation of geographic security assertion 118 is “AO+”, attainedonce again via processing the geographic security assertion 118 inrelation to the information 120, arriving at the abbreviated low-leveldefinition.

Calculating the compact representation of a geographic securityassertion 116 involves translating or defining the high-level elementsof the assertion into low-level constitutive elements. Once processingis complete, the low-level constituents must map or relate to protocolcharacteristics defined within Information 120 and associated withgeographic regions or information related to geographic regions. Thesymmetry between the protocol characteristics of the low-levelconstituents in relation to Information 120 allows the geographicsecurity device 110 to take selective action on network information bybasing that action upon low-level protocol characteristics extractedfrom incoming network information. The veracity of Information 120ensures that the filtering of traffic on the basis of low-levelconstituents accurately implements the geographic security assertionsand reflects the geographic relationships embodied in those assertions.A security assertion such as “BLOCK ZA” is translated on the basis ofInformation 120 into an actionable set of low-level protocolcharacteristics, which can be detected in incoming and outgoing networkcommunications. In one example, network information inbound from ZA isblocked 112 by the geographic filter device 110 on the basis of thedetection and response to protocol characteristics contained within thecommunication stream and represented within the geographic filter device110 as the low-level constituents “ZA−”. In another example, outboundtraffic to region AO 124 is allowed by the geographic filter device onthe basis of the low-level constituent definition “AO+”.

A key aspect of the functioning of the geographic filter device has beenglossed over, namely, the relationship between security assertions andthe low-level constituent definitions of such assertions within thegeographic filter device. FIG. 2, shows the logical relationship betweensecurity assertions and low-level constituent definitions in moredetail. In a traditional firewall, the “security rules” play an integralrole in device functioning, so much so, that a firewall without rulesdoes nothing. Moreover, rules occupy a central space within firewallmemory and play an integral function in determining which packets areallowed to pass and which are dropped by the device. Unlike a firewall,the geographic filter device has no rules in the ordinary sense of afirewall rule. Rather, preliminary processing of a geographic securityassertion 116 eliminates the assertion and replaces it with anequivalent representation of low-level constituents 206. Additionally,as a result of this processing, the mode in which the constituents areinstantiated within the geographic filter determines a security action.As such, actions by the geographic filter device that block or droptraffic, allow traffic, reroute traffic, log traffic, etc., aredetermined by a contextual property of a memory structure 208 ratherthan the syntactic and semantic properties of a rule.

Terminologically, a geographic security assertion 116 is parsed into aResource Identifier 204 and a Device Action 202. The Device Action 202determines the contextual mode of storage 208. A “Resource Identifier” aterm that describes an object or token extracted from Information 120,FIG. 1, and employed during the operation of a geographic filter.Importantly, Resource Identifiers have various levels of cardinality asdetermined by the totality of geographic relationships extracted fromInformation 120, in FIG. 1. Resource Identifiers such as “Europe”,“Asia”, “Eurasia”, “United States”, “US”, “Texas”, or “TX” are all validResource Identifiers, thus a challenge is introduced. ResourceIdentifiers must be translated into actionable sets of low-levelprotocol attributes in order to have meaning within the geographicfilter device. Within security assertions, Resource Identifiers can beof a highly general type, as can Device Actions. Thus securityassertions can be of varying degrees of generality, the most generalbeing, sentential construction in a language such as English. Naturallanguage geographic security assertions we refer to as “informal.” Suchassertions could then be processed via a natural language interpreterinto a formal representation, that is, a uniform syntax usable by thegeographic filter. For example, a formal geographic security assertioncould be derived by parsing the following informal sentence. Note,natural language processing is not required, as an informal geographicsecurity assertion could be build using a series of World maps or moregermanely by using an “Assertion Wizard” within a Graphical UserInterface, allowing the user to choose pre-defined words and phraseswhen creating an informal geographic security assertion:

(Example. 1) “Do not allow any network traffic to be sent or receivedfrom South Africa”(Example. 2) “Only allow network communication from NATO countries”

FIG. 2, shows the base formal translation of (Example. 1) withingeographic security assertion 116. This formal geographic securityassertion is then broken apart into a Device Action “BLOCK” 202, and aResource Identifier “ZA” 204. The Resource Identifier 204 is furtherbroken down through successive processes of definition into a low-levelset of constituents 206. Example of a low-level protocol constituentwould be an IP address expressed as a 32-bit integer, in a Start-Endblock format. The full set of low-level constituents a,b,c,d,e,f,g 206,would constitute the totality of low-level constituents derived from theResource Identifier “ZA” 204. Finally, the low-level constituents 206are instantiated into a memory structure 208. Contextually, placementwithin memory structure 208 determines the device action “BLOCK” for alllow-level constituents 206 processed by the information processingarchitecture of 208. In a highly simplified example, memory structure208 can be thought of as a list, and thus the act of placingconstituents 206 within the memory structure list 208 results in theDevice Action of “BLOCK” being applied to any network traffic exhibitingthe protocol attributes or characteristics stored within memorystructure list 208. If the protocol attributes were stored in memorystructure list 210, the Device Action would differ, for example, “ALLOW.

In (Example 2) the scenario is more complex, as “NATO Countries” is anabstract Resource Identifier, the meaning of which can change based oninternational politics. Thus accurately translating this assertionrequires an accurate list of NATO membership and the ability totranslate “NATO Countries” into a list of formal Resource Identifierscorresponding to NATO membership. As such, the translated rule willconsist of multiple formal Resource Identifiers and one Device Action.

Having provided a very general description of the operation of ageographic filter, it will now be explained in more detail how thematching of low-level constituents derived from Resource Identifiers toa protocol communication channel results in the performance of DeviceActions.

FIG. 3, shows an example geographic filter device performing a deviceaction within a basic geographical topology. The geographic filterdevice 110 examines all inbound and outbound network communicationswhich it has been configured to monitor. The network object 108 is showncommunicating with geographic region “AO” 124, the flow of thedirectional arrows indicating the direction of the traffic originatingfrom 108 and transmitting to geographic zone “AO” 124. Additionally,geographic region “ZA” 122 is depicted as attempting to communicatethrough the geographic filter device 110, the directional arrowsindicating network traffic inbound to the geographic filter device 110.The memory structure 308 is depicted as containing among other things alist of IP addresses. Note, memory structure 308 is depicted in FIG. 3in a highly generalized manner, that is, memory structure 308 would inactuality not contain information such as “ZA” or “Block”, but it wouldonly contain IP addresses. Overlooking this for now, it can be said thatmemory structure 308 when in operation approximates the function ofexamining the incoming communication pathway and the outgoingcommunication pathway for the purpose of performing Device Actions onthe communication pathways. Device Actions are triggered by memorystructure 308 in virtue of examining the incoming and outgoingcommunication pathways and matching low-level protocol constituentscontained within 308 with low-level protocol attributes within eithercommunication pathway.

A successful match is shown in FIG. 3, along with the performance of aDevice Action. Memory structure 308 location 310 contains within it thelow-level constituent “41.192.1.1” shown in memory location 310. Thelow-level constituent “41.192.1.1” 310 is a constituent of geographicregion “ZA” as shown in memory location 310. The incoming communicationpathway is examined, or parsed to be more specific, and protocolattributes are extracted. The result of this operation is the extractionof 302, a low-level protocol attribute 302 of the incoming communicationchannel. Next, this extracted protocol attribute 302 is compared againstthe content of memory structure 308 to determine if a matching low-levelconstituent exists within the memory structure. This process ofcomparison, or analysis, involves searching through, or iterating over,the contents of the memory structure 308 and comparing the value of theextracted protocol attribute 302 to the value of the constituent valuescontained within 308. A positive match in this case occurs whensearching memory location 310, resulting in the performance of theDevice Action “BLOCK”, as indicated by juncture 306. Transmission of theinbound communication channel to other systems is prevented as a resultof the positive match. In this example, the return value of the analysisoperation performed in 304 is the Device Action “BLOCK” indicated by theminus sign 112. This Device Action is applied to the inboundcommunication pathway, as shown in 112.

Returning briefly to FIG. 1, the geographic filter system has two mainconfiguration pathways: Information 120 and geographic securityassertions 116, 118. Other configuration pathways exist and will be thesubject of later discussion. Although the general aspects of the overallfunctioning of the geographic filter device 110 have been described,comparatively little has been said about the characteristics ofinformation 120 and how this information enables the translation ofgeographic security assertions 116, 118 into low-level constituents.This functionality will now be explored in greater detail.

In order to explain the process whereby geographic security assertionsare reduced to low-level constituents, it is helpful to consider a basicscenario. First, as previously discussed, configuration informationregarding geographic regions or data related to those regions can beinput in the form of a list. A common example of such a list is adelegated-list as published by Regional Internet Registrars (RIRs) suchas ARIN, APNIC, AFRINIC, LACNIC, or RIPENCC. Geographic information isalso available from other sources, such as public or licensed geographicdatabases. For purposes of explanation, we will show the use of an RIRdelegated list. The underlying mechanisms are the same regardless of themedia type used to supply the geographic information. Our scenario willbe further simplified by the assumption that the world consists only ofgeographic regions ZA (“South Africa”), BW (“Botswanna”), AO (“Angola”),and NA (“Nambia”). Additionally, the location of the geographic filterwill be excluded from the example, as consideration of this location isunnecessary for the purpose of explaining the processing and utilizationof configuration information.

The RIR delegated list for AFRINIC in our example consists is a list of“316 lines”; each line corresponds to an IP address range associatedwith a Country. Country Codes within this example are ISO 3166 CountryCodes as maintained by the International Organization forStandardization.

The portion of the delegated list relevant for BOTSWANA (BW) is shownbelow, containing “2 lines” (Example 3):afrinic|BW|ipv4|196.1.130.0|1024|19940509|assignedafrinic|BW|ipv4|196.45.164.0|1024|20050705|allocatedThe portion of the delegated list relevant for NAMBIA (NA) is shownbelow, containing 7 lines (Example 4):afrinic|NA|ipv4|196.1.28.0|1024|20041027|allocatedafrinic|NA|ipv4|196.3.94.0|256|19950404|assignedafrinic|NA|ipv4|196.20.0.0|8192|19950103|allocatedafrinic|NA|ipv4|196.44.128.0|8192|20010621|allocatedafrinic|NA|ipv4|196.45.0.0|4096|20021004|allocatedafrinic|NA|ipv4|196.216.32.0|8192|20050823|allocatedafrinic|NA|ipv4|204.152.14.0|512|19941013|assignedThe portion of the delegated list relevant for ANGOLA (AO) is shownbelow, containing 9 lines (Example 5):afrinic|AO|ipv4|41.222.2 4822.0|2048|200603131|allocatedafrinic|AO|ipv4|41.223.0.0|1024 1200603091|allocatedafrinic|AO|ipv4|196.29.192.0|4096|20000724|allocatedafrinic|AO|ipv4|196.32192.0|2048|20051207|allocatedafrinic|AO|ipv4|196.45.160.0|1024|200406151|allocatedafrinic|AO|ipv4|196.46.72.0|2048|200508101|allocatedafrinic|AO|ipv4|196.202.252.0|1024|20050419|allocatedafrinic|AO|ipv4|196.216.136.0|1024|20060120|allocatedafrinic|AO|ipv4|196.223.1.0|256|20060105|assignedThe portion of the delegated list relevant for South Africa (ZA) isshown below, containing 298 lines (Example 6):afrinic|ZA|ipv4|196.11.117.0|1280|19940710|assignedafrinic|ZA|ipv4|196.11.122.0|256|19941109|assignedafrinic|ZA|ipv4|196.11.123.0|256|19940710|assignedafrinic|ZA|ipv4|196.11.124.0|256|19940524|assignedafrinic|ZA|ipv4|196.11.125.0|2560|20020521|assignedafrinic|ZA|ipv4|196.11.136.0|2560|19941109|assignedafrinic|ZA|ipv4|1196.11.146.0|1024|19940710|assignedafrinic|ZA|ipv4|196.11.160.0|2560|19940710|assignedafrinic|ZA|ipv4|196.11.170.0|1280|19940524|assignedafrinic|ZA|ipv4|196.11.188.0|256|20021120|assigned(list truncated)

Taken together, the associated information for ZA, BW, AO, and NAconstitutes the totality of geographic information available to thegeographic filter device. This information is next processed from itsraw form into a format the geographic filter system may utilize forfurther operations. Additionally, a unique parsing mechanism isemployed, a mechanism that is programmatically capable of reading in thesyntax of the RIR delegated list for AFRINIC.

FIG. 4 demonstrates the unique parsing mechanisms that must exist forany media type used the geographic filter, and the embodiment of suchparsing within a specialized input processing engine, the FunctionalInput Engine 402.

In our example, the RIR delegated list for AFRINIC is read in by theFunctional input Engine 402, the information passed to the ConfigurationPost-Processing Engine 404 for encoding, conversion, and optimizationprocesses. By process of encoding the data from the delegated list isextracted according to a parsing algorithm, and non-relevant segments ofthe data are trimmed off or discarded. For instance:

The portion of the delegated list relevant for BOTSWANA (BW) is shownbelow, comprising 2 lines (Example 7):(afrinic,BW,196.1.130.0,1024)(afrinic,BW,196.45.164.0,1024)

Once encoded in this format, the concept of a line is purely an analogy,as the representation is no longer a literal line in a text file, but amember of a set having a particular address in memory. Regardless, theanalogy of lines will be continued for the sake of simplicity.

Conversion processes take place within the Configuration Post-ProcessingEngine 404, involving the translation of particular units of informationinto alternate forms. One way to convert the IP address 196.1.130.0 isto convert it into a 32-bit integer, as shown in Example 8 below. Theresult of this conversion would produce the following data set (Example8):

(afrinic,BW,3288433152,1024)(afrinic,BW,3291325440,1024)

Next, an optimization algorithm is performed over the converted dataset. Depending upon the type of conversion operation the method ofoptimization may differ. In the case of 32-bit integers, one key mannerof optimizing the data set in (Example 8) is to combine contiguousnetwork ranges. Another method of optimization for “dotted quad”representation of (Example 7) is to perform a “Uniqueness” operation. InExample 7, the parsing process produces an IP address followed by thenumber of IP addresses contiguous with the starting address, thus196.1.130.0 is followed by 1024 possible IP addresses. Thus BW has beenassigned the address 196.1.130.0 and the following 1024 contiguousaddresses for use. Additionally BW has also been assigned a differentnetwork range for use, the 196.45.164.0 starting address followed by1024 possible IP addresses contiguous with that starting address. A“Uniqueness” optimization would begin with the first octet of the IPaddress in the first row of data and compare this octet to the leadingoctets of the IP addresses for all other countries in the totality ofthe geographic data set. In our specific example, the IP addressassignments for AO, ZA, and NA would be searched for a leading octet ofthe value “196.” If this value were not present in any of the other IPaddress assignments for AO, ZA, and NA, then all addresses within BWwould be optimized into the largest possible network representation thatdoes not change the base IP address, as shown in (Example 9):

(afrinic,BW,3288433152,16,000,000)

This type of data compression is reliable because there are no other IPaddresses beginning with “196.” assigned to any other geographicregions. In CIDR notation, the “Uniqueness” algorithm would produce thefollowing CIDR block (Example 10):

(afrinic,BW,196.0.0.0\8)

The application of compression algorithms to the geographic informationthus allows rows to be eliminated from the total dataset, either throughcollecting and compressing contiguous network blocks or throughuniqueness operations. The benefit of reducing the dataset is that itbecomes necessary to search through fewer regions of memory whenattempting to locate an IP address within a list of IP addresses.Through the application of a “Uniqueness” algorithm it is possible toproduce vastly smaller data sets during conversion and optimizationalgorithms. For instance, applying the “Uniqueness” algorithm to thegeographic data set for South Africa (“ZA”) dataset has the following(Example 11), containing “87 lines”:

afrinic|ZA|ipv4|196.11.117.0|1280|19940710|assignedafrinic|ZA|ipv4|196.11.122.0|256|19941109|assignedafrinic|ZA|ipv4|196.11.123.0|256|19940710|assignedafrinic|ZA|ipv4|196.11.124.0|256|19940524|assignedafrinic|ZA|ipv4|196.11.125.0|2560|20020521|assignedafrinic|ZA|ipv4|196.11.136.0|2560|19941109|assignedafrinic|ZA|ipv4|196.11.146.0|1024|19940710|assignedafrinic|ZA|ipv4|196.11.160.0|2560|19940710|assignedafrinic|ZA|ipv4|1196.11.170.0|1280|19940524|assignedafrinic|ZA|ipv4|196.11.188.0|256|20021120|assignedafrinic|ZA|ipv4|196.11.192.0|1280|19940524|assigned(list truncated)

The data set resulting from converting this optimized set to 32-bitintegers and further compressing contiguous blocks is shown below(Example 12), containing “75 lines”:

(afrinic,ZA,3289085184,4608)(afrinic,ZA,3289090048,3584)(afrinic,ZA,3289096192,3840)(afrinic,ZA,3289103360,256)(afrinic,ZA,3289104384,3584)(afrinic,ZA,3289108480,5888)(afrinic,ZA,3289114624,512)(afrinic,ZA,3289115392,3840)(afrinic,ZA,3289119744,768)(list truncated)

The “Uniqueness” algorithm can execute successive operations, such asanalyzing the second and following octets for uniqueness relative to thetotality of geographic information. Such an operation, not shown here,should be evident based on the information presented here to anyoneskilled in the art.

Algorithms of parsing, encoding, optimization, and conversion, havingbeen performed by the Configuration Post-Processing Engine 404 in FIG.4, the processed information is then stored, either in memory, on thefile system, or within a database, for use by the ConfigurationPost-Processing Engine 404 when analyzing security assertions. For thecontinuation of this example four formal security assertions areintroduced, (Example 13):

BLOCK ZA ALLOW AO ALLOW NA BLOCK BW

The geographic security assertions are received by the ConfigurationPost-Processing Engine 404, FIG. 4, and are sorted by their DeviceActions, producing two associated sets, in this example. Additionally,any other processing, such as in the case when the geographic securityassertions are supplied in an informal representation from the UserInterface Engine 406 or Functional Input Engine 402, is performed so asto convert the informal geographic security assertions into formalgeographic security assertions. The two sets of geographic securityassertions are then defined in terms of an appropriate low-levelrepresentation, as seen in Example 13, the two lists are converted intolists of 32-bit integer addresses in a start addresses, number ofcontiguous IP address, representation (32-bit Start-End format) (Example14):

ALLOW BLOCK ----- ----- (x lines) (y lines)

The “BLOCK” list from Example 14 contains y lines, constituting the ymembers of the set of 32-bit integer start-end representations derivedfrom converting Examples 4 and 5, which has not been shown but should beevident to one skilled in the art. The members of the “BLOCK list” are,abstractly, a Device Action group, which for definitional purposes wewill call the group (y). The use of (y) as a designator indicates thatthe group is in a blacklist or “BLOCK” state. The “ALLOW list” isdefined as group (x), the (x) designator indicates the group is in awhitelist state, or “ALLOW” state.

The Configuration Post-Processing Engine 404 then performs a sizecomparison algorithm of the two groups. The result of the comparisonreturns the smallest group and the degree in size difference. If thedifference surpasses a heuristic threshold, then the smaller group isselected. Considering particular threshold values is unimportant,however the purpose of the comparison is to identify the smallest setwhen the difference is significant, where a significant differenceshould be clear to anyone skilled in the art. Importantly, the result ofthis comparison involves checking the state of the Geographic FilteringEngine 408 FIG. 4, where the Geographic Filtering Engine 408 may be in 2possible filter states.

A “whitelist” state indicates that the low-level constituents populatingthe geographic filter memory structure specify communication protocolattributes that must be present for network information to pass throughthe geographic filter. A “blacklist” state indicates the low-levelconstituents define protocol attributes that must be absent in networkinformation for the network information to pass through the filter. Whenthe low-level constituents are IP addresses in a whitelist state, theconstituents specify IP Addresses that are allowed to communicate withprotected network objects. When the low-level constituents are IPaddresses in a blacklist state, the constituents specify IP Addressesthat are not allowed to communicate with protected network objects.

As a result of a geographic filter state check function, the currentstate of the Geographic Filtering Engine 408 is reported to theConfiguration Post-Processing Engine 404 as one of two values: value(y)for “blacklist,” and value(x) for “whitelist”. Thus the two possiblegroup states (group(x), group(y)) and the two possible filter states(value(x), value(y)), yield four operations for updating the GeographicFiltering Engine 408 with a new set of low-level constituents:

When the state value of the Geographic Filtering Engine 408 is value(x)and when group(x) is significantly smaller than group(y), then group(x)is used to update the Geographic Filtering Engine 408 without executinga filter state change function.

When the state value of the Geographic Filtering Engine 408 is value(x)and when group(y) is significantly smaller than group(x), then group(y)is used to update the Geographic Filtering Engine 408 and a filter statechange function is executed.

When the state value of the Geographic Filtering Engine 408 is value(y)and when group(y) is significantly smaller than group(x), then group(y)is used to update the Geographic Filtering Engine 408 without executinga filter state change function.

When the state value of the Geographic Filtering Engine 104 is value(y)and when group(x) is significantly smaller than group(y), then group(x)is used to update the Geographic Filtering Engine 408 and a filter statechange function is executed.

The scenario we have presented exemplifies the process by whichhigh-level geographic security assertions are examined, optimized, andfinally translated into a low-level set of constituents, whichillustrates one narrow embodiment of the present invention disclosedherein. It would be obvious to those skilled in the art that certainchanges and modifications to the aforementioned processes and steps donot depart from the scope of the present invention. For example,additional methods of encoding, conversion, and optimization, whilediffering from those specific means of encoding, conversion, andoptimization mentioned herein, do not substantially change the scope ofthe invention. Moreover, while a particular embodiment of the presentinvention has been disclosed herein in a limited way, it would beobvious to those skilled in the art that the scope of the invention isnot limited to any particular protocol within the IP Protocol family,including encapsulated protocols. The scope of the invention is also notsubstantially changed by implementation, as one skilled in the art wouldagree that the processes described herein are neutral with respect toany particular computer system or computer architecture, such that thepotential for embodying the method on a variety of different servertypes or different network devices requires minor changes that do notsubstantially depart from the scope and method of the present invention.

Since the previous discussion glossed over many of the importantengines, modules, and functions of the geographic filter system, a moredetailed explanation of each of the major engines, modules, andfunctions is in order. At the highest level of abstraction, shown inFIG. 1, the present invention consists of the following components: aUser Interface Engine 406, a Configuration Post-Processing Engine 404, aTranscoding-Parsing Engine 410, a Functional Input Engine 402, aGeographic Filtering Engine 408, a Network Filtering Engine 412, aTranscoding-Output Engine 414, and a Reporting Engine 416. Each engineconsists of one or more modules. Each module may operate in one or moremodes, or perform one of more functions. Below, each major engine,module, and function comprising the present invention is described ingreater detail.

FIG. 4, a USER INTERFACE ENGINE 406 in which geographic rules andconfigurations are declared and logging data from geographic filterdevice operation is displayed to the user in accordance with a number ofmodalities. The User Interface Engine 406 includes user configurablecriteria for displaying logging and reporting information on a graphicalworld map.

One such criterion is a zoom level, enabling the user to adjust theperspective of the map from among several possible perspectives,including: world perspective, continental perspective, and countryperspective, or user-defined perspective using customized ResourceIdentifiers defined by the user. Adjustments in zoom-level dynamicallyaffect the presentation of data within the map such that only eventsrelevant to the visible surface area of the map are presented, asdetermined by the zoom level in conjunction with the user configurationpertaining to which types of statistical and operational data should bedisplayed. Changes in map perspective are context sensitive inaccordance with a user's preference between absolute and relativecenter, such that utilizing a relative center positions the focal pointof the map beneath the users mouse cursor, following an actuation of themouse via a button press. Changes in map perspective are contextsensitive in accordance with a user's preference between absolute andrelative center, such that utilizing an absolute center positions thefocal point of the map in the middle of the Resource Identifiercurrently selected, following an actuation of the mouse via a buttonpress in accordance with the zoom level. In this way, the user caneasily select countries to block or metrics about a country relative tothe geographic filter, among other configuration options.

Several facilities within the User Interface Engine 406 allow forspecifying geographic security assertions. Geographic securityassertions can be defined by the user manually by typing the assertionwithin a particular window or field. Alternately, the user can employ agraphical world map for defining security assertions by interactivelyselecting regions and sub-regions and interactively selecting ResourceIdentifiers and Device Actions in a context sensitive menu.

Another method includes using a geographic security assertion “Wizard”to iteratively define a security assertion by selecting from a number ofpre-configured choices and options. The user may also load aconfiguration file from a stored configuration, representing a previousstored state.

FIG. 5, a CONFIGURATION POST-PROCESSING ENGINE 404 made up of fourseparate modules, a Post-Processing Functional Input Module 502, whichreceives input from the Functional Input Engine 402, a Post-ProcessingUser Input Module 504 which receives and parses input from the UserInterface Engine 406 and propagates the result to a Post-ProcessingOptimization Module 506, the purpose of which is to apply a set ofCompression-Abstraction Algorithms to the user-supplied configuration,resulting in a set of optimized device configuration instructions, and,to transmit this information to the Post-Processing Output Module 508,which translates the optimized device configuration instructions intomachine instructions suitable for configuring the componentsfunctionally linked to the Configuration Post-Processing Engine 404.

Functionally linked to the Configuration Post-Processing Engine 404 area Transcoding-Parsing Engine 410, a Functional Input Engine 402, and aNetwork Filtering Engine 412 and a Geographic Filtering Engine 408.

The Configuration Post-Processing Engine 404 performs the high leveltask of ensuring that configuration information is formatted andoptimized for efficient use. The three major types of configurationinformation are security assertions, the geographic information used fordefining those assertions, and the various operational parameters that auser may establish during configuration. Additionally, configurationinformation is often updated in real-time, such that the securityassertions change, or the information for defining those assertions isupdated, and/or an operational parameter is changed. One example of anoperation parameter might be whether the geographic filter device logsdata in one format or another. Another operational parameter might be amode that controls the overall functioning of the geographic filterdevice. The Configuration Post-Processing Engine 404 ensures thatconfiguration changes, as well as, types of configuration information,such as input from a geographic database or list, are transmitted to theappropriate geographic filter device engines and components bysupplementing the processed and optimized configuration information withmeta-information provided by the Output Module 508 that is used tocontrol the flow and utilization of configuration by other engines.

The Configuration Post-Processing Engine 404 has a User Input Module 504and a Functional Input Module 502, each processing a different type ofconfiguration input. The Functional Input Module 502 provides ainterface to the Functional Input Engine 402, with parsing mechanismsunique to the information supplied by that Engine. For example, theFunctional Input Module 502 processes information that includes dataimported from text files, hypertext-markup language files (.html), orinformation retrieved from a database via an ODBC or similar protocol.The User Input Module 504 processes other kinds of information, such assecurity assertions defined within a Graphical User Interface, or via auser's typing into a console window or command shell, or operationalparameters supplied by a user during operation through any number ofmeans.

Optimization processes carried out by the Optimization Module 506include functions for data encoding and decoding, data type conversion,the conversion of IP addresses into alternate representations. In somecases, optimization algorithms may require input from other Engines,such as the Geographic Filtering Engine 408 Associative Module 804.Three specific types of conversion mechanisms for IP Addresses that areemployed are converting an IP Address Range into a 32-Bit Integer beingthe start address, and a number corresponding to the number ofcontiguous IP address (32-Bit Start-End format). Another conversion typeis a range notation using a dash within a dotted-quad format (RangeNotation). Still another type of conversion is to convert an IP addressRange or List into Classes Inter Domain Routing (CIDR) representation.The Perl Script below gives an example of these types of conversionmechanisms:

!/usr/bin/perl -w use strict; # convert address(int),len to CIDRnotation sub intrange2cidr {     my @ranges = ( );     my $start =$_(0);     my $len = $_(1);     my $mask = 0;     my $macked = 0;    while ($len>0)     {             # Find the largest possible maskthat we             # could apply without altering the ip address        $mask=33;         do         {             $mask−−;            $masked = $start & (2**(32−$mask));         }         while($masked==0);             # Now work backwards and find the largest            # mask that is less than or equal to the             #remaining length         while ((2**(32−$mask))>$len)         {            $mask++;         }             # Output the CIDR notation,calcualte the             # new start address and lengths and continue        my $complen = (2**(32−$mask));         my $output =int2ip($start).“/”.($mask);         push(@ranges, $output);         $len−= $complen;         $start += $complen;     }     return @ranges; } #convert X.X.X.X to int sub ip2int {    my @ip = split(‘\.’, $_(0));   return ($ip(0)*256*256*256)+($ip(1)*256*256)+($ip(2)*256)+    $ip(3);} # convert int to X.X.X.X sub int2ip {    my $ip = $_(0);    return(($ip>>24)%256).“.”.(($ip>>16)%256).“.”.(($ip>>8)%256).“.”.($ip%256); }sub output {    my $numip = $_(0);    my $len = $_(1);    print$numip.“,”,$len.“\n”;    my $sip = int2ip($numip);    my $eip =int2ip($numip+$len−1);    my $xip = $sip.“-”.$eip;    print $xip.“\n”;   foreach (intrange2cidr($numip,$len))    {       print $_.“\n”;    } }my %ips = ( ); if (@ARGV==0) {    print “Usage: $0 COUNTRY_CODE\n”;   exit; } my $country = $ARGV(0); open(TMP,“<master.txt”); while(<TMP>) {    if (/$country\|lipv4/)    {       my @row = split(‘\|’,$_);       my $len = $row(4);       my $numip = ip2int($row(3));      $ips{$numip} = $len;    } } close(TMP); my $lastnumip = 0; my$newlen = 0; foreach my $key (sort {$a <=> $b} keys %ips) {    my $numip= $key;    my $len = $ips{$key};    if (($lastnumip + $newlen) ==$numip)    {       $newlen += $len;    }    elsif ($lastnumip != 0)    {      output($lastnumip, $newlen);       $lastnumip = $numip;      $newlen = $len;    }    else    {       $lastnumip = $numip;      $newlen = $len;    } } if ($lastnumip != 0) {   output($lastnumip, $newlen); } print “\n”;

It should be evident to one skilled in the art that other conversionroutines and optimization steps can be used by the Optimization Module508 without departing from the spirit of the invention.

FIG. 6, A TRANSCODING-PARSING ENGINE 410 made up of three separatemodules: a Parser-Input Module 602, which functions to interoperate andencode portions of the Run-Time Input Medium 418 depending on the ParserInput Mode, a Parser-Output Module 606, which propagates the parsedinput to the Geographic Filtering Engine 408 according to aParser-Output mode, and, a Parser-Configuration Module 604, whichreceives input from the Post-Processing Output Module 508 and sets theParser-Input Mode and the Parser-Output Mode.

The Parser-Input Module 602 of the Transcoding-Parsing Engine 410interprets and encodes portions of the Run-Time Input Layer 418 based onits configuration by the Parser-Configuration Module 604, with respectto which the Parser-Input Module 602 can be configured in three inputmodes:

Mode 1 602-A being to receive Internet Protocol version 4 or version 6data packets (IP Layer 3) from either a network interface card (NIC) orOperating System component, such as a kernel memory device or anOperating System device-driver, and to parse the input, extracting andencoding the Source and Destination Address of each of the plurality ofdata packets received by the Parser-Input Interface.

Mode 2 602-B of the Parser-Input Module (102-A) receives as input adevice log or other file matching a supported log or storage format,such as a PCAP log. One example of such a log is the packet captureformat (PCAP) supported by the program tcpdump. Another example of a Logformat is a web server access log, such as the log generated by theApache Web Server. Another example could be a list of IP addresses in atext file in CSV format, or stored in Rich Text Format (.RTF), Unicode,or Plain Text file (.txt) file.

Mode 3 602-C of the Parser-Input Module is to receive input from aprocess, such as from input from another module, or input from anotheroperating system device or process, such as from a TCP socket, or stdin.

The Parser-Output Module 606 of the Transcoding-Parsing Engine 410 sendsoutput to functionally related engines and components based on theconfiguration supplied by the Parser-Configuration Module 604, withrespect to which the Parser-Output Module 606 can be configured tosupport three output modes:

Mode 1 606-A output propagates an IP Address to the Geographic FilteringEngine 408, with a VALIDATE instruction.

Mode 2 606-B output propagates either an IP Address or ASN (AutonomousSystem Number) to the Geographic Filtering Engine 408 with a TRANSFORMinstruction.

Mode 3 606-C output propagates a optimized rule set in a supportedformat which is either processed in real-time by the Rules AbstractionModule or passed to the Transcoding-Output Engine.

The three input modes 602-A, 602-B, and 602-C and three output modes606-A, 606-B, and 606-C are different ways of receiving and processingthe full range of possible input that can be received during run-timeoperation. Rarely will a device operate using all three modes at once,but rather, the different modes correspond to different baseconfigurations. Moreover, many geographic filter device architecturesmay prefer one mode of operation over another, whereas some geographicfilter devices may switch between one or more of the modes dynamically.For example, Input Mode 3 602-C enables a local or host-based geographicfilter device to monitor kernel messages or operating system messages.One example embodiment of the present invention would, therefore be, alocal geographic filter device utilizes input mode 3 602-C to monitorinformation contained within the Microsoft Windows 2K/XP “event log” ormonitors “/var/log/messages” on linux or unix systems, thisfunctionality, henceforth, will be referred to as operating in localmode. Offline mode, or forensic mode, embodies utilizing Input Mode 2602-B to perform geographic analysis over network information recordedor logged by a device. In other example embodiment is a Metrics Mode,using Input Mode 602-A, in which network communications are merelymonitored, categorized, and statistically analyzed for geographicrelationships. In Security Mode, or Policy Enforcement Mode, Input Mode602-A is used in conjunction with particular geographic securityassertions that result in the enforcement of one or more securitypolicy, regulatory compliance, and proactive security models bygeographically regulating network traffic.

FIG. 7, A FUNCTIONAL INPUT ENGINE 402 comprised by a Loader Module 702and a Media Interface Module 704. The Media Interface Module 704performs the processes for opening, reading, or retrieving the desiredmedia type from its location. This module is responsible for reading ofthe input from a source media, such as a file on the hard-disk. TheLoader Module 702 is responsible for loading a media into memory forprocessing by the Transcoding-Parsing Engine 410. The Loader modulereceives input from the Media Interface Module 704 and sends its outputto the Parser-Input Module 602 which processes the input according toone of three modes 602-A, 602-B, 602-C. The Functional Input Engine 402performs initial loading, parsing, and processing of input types thatcorrespond the three Input Modes of the Transcoding-Parsing Engine 410.

Unlike the Transcoding-Parsing Engine 410 which uses informationprocessed from kernel messages, device logs, or the networkcommunication layer, the Media Interface Module 704 contains theapparatus necessary to gather information from sources such as kernelmessages, device logs, files, or network communications channels. Havingthe appropriate media interface allows the Functional Input Engine 402to tap into a particular source of information and make that informationavailable to the Transcoding-Parsing Engine 410, or other functionallyrelated components. The Loader Module 702 extracts the processedinformation from the media interface and transmits this information toother Geographic Filtering Engines and components.

Importantly, the Functional Input Engine 402 can receive networkcommunications of various types from other geographic filter devices orother network objects. Additionally, the media interface is not passivein this regard, but may query an external device or information sourceand make this information available to the Transcoding-Parsing Engine410 or the Configuration Post-Processing Engine 404. Configurationinformation, for example, can be retrieved from a remote location,including the retrieval of updated geographic information, orinformation concerning security policy to be implemented by thegeographic filter device, additional security assertions from a remotelocation. The Functional Input Engine 402, thus enables anotherembodiment of the present invention, a real-time threat feed. SecurityAssertions are regularly retrieved from another geographic securitydevice or another information processing repository and these securityassertions are optimized and loaded based on user configuration, whichis, based on the configuration of operational parameters relating to thethreat feed.

FIG. 8, a GEOGRAPHIC FILTERING ENGINE 408 is composed of a GeofilterControl Module 802, which receives input from the Transcoding-ParsingEngine 410 in accordance with one of three modes 606-A, 606-B, 606-C, anAssociative Module 804, which processes information on request by theGeofilter Control Module (XXX), a Rules Abstraction Module 806, whichcontains a compact representation of security assertions in the form oflow-level constituents, and a Dispatch Module 808, which reports theresult of Geographic Filtering Engine 408 functioning to otherfunctionally related engines and components.

The Geofilter Control Module 802 internalizes the Geographic FilteringEngine 408 logic, enabling logical, arithmetic, and associativefunctions to be carried out by the geographic filter. These logicaloperations are described here as a Transform Function (delta), aValidate Function (Sigma) and a Populate Function (alpha). Execution ofany of these Functions involves transmitting and receiving data fromvarious Geographic Filtering Engine 408 Modules, although thecommunication pathway between the Modules differs with regard to eachFunction.

A TRANSFORM FUNCTION, represented in FIG. 8 as (A), triggers theAssociative Module 804 to calculate a result as part of an associativeoperation for a given input. A few examples of the types of associationoperations this module performs are: Resource Identifier to ResourceIdentifier, IP Address to ASN, IP Address to an ISO Country Code, ASNnumber to IP Address, ASN number to IP Address, ISO Country Code to IPNetwork Ranges, Net blocks, or CIDR blocks, and Country Code to ASNnumbers. Terms such as “ASN,” “ISO Country Code,” “Net blocks,” or “CIDRblocks,” where not previously defined, would be evident to one skilledin the art.

The Associative Module 804 is capable of deriving logical associationsbetween Resource Identifier Groups defined by the user. Thus, anyarbitrary Resource Identifier defined by the user can be translated andassociated with other related information provided the user has inputthe correct information during definition of the Resource Identifier.Additionally, some associative operations, depending upon the desiredresult, will be recursive and involve iterative processes of definitionand redefinition by the associative module.

A VALIDATE FUNCTION, represented in FIG. 8 as (E), triggers the RulesAbstraction Module 806 to search its memory structure contents for aparticular IP Address, whereas finding the IP address within thestructure constitutes a positive match. Not finding the IP Addresswithin the memory structure results in a negative match. Depending uponthe state-value of the memory structure, a positive match triggers adevice action, this being determined by the contextual property ofstorage. For purpose of explanation, consider the Validate Function toreturn one of two values, a “+” for a positive match, and a “−” fornegative match, where positive + indicates the presence of the matchedobject within the memory structure, and negative indicating the absenceof the object from the memory structure. Additionally, value(y) of thememory structure is a blacklist state, and value(x) is a whiteliststate. Based on the state-value of the Rules Abstraction Module 806 adevice action will be transmitted to the Dispatch Module 808 as a resultof the Validate Function. (Σ).

When the state value of the Rules Abstraction Module 802 is value(x)(i.e. whitelist, or ALLOW) and when the match value is (+), then thecontextual property of the memory structure is transmitted to theDispatch Module 808 as a Device Action Code (DAC).

When the state value of the Rules Abstraction Module 802 is value(y)(i.e. blacklist or BLOCK) and when the match value is (−), then thecontextual property of the memory structure is NOT transmitted to thedispatch module as a Device Action Code (DAC), but a “No Operation” istransmitted to the Dispatch Module 808.

When the state value of the Rules Abstraction Module 802 is value(y) andwhen the match value is (+), then the contextual property of the memorystructure is transmitted to the Dispatch Module 808 as a Device ActionCode.

When the state value of the Rules Abstraction Module 806 is value(x) andwhen the match value is (−), then the contextual property of the memorystructure is NOT transmitted to the dispatch module as a Device Action,but a “No Operation” is transmitted to the Dispatch Module 808.

A POPULATE (α□) function may be sent to the Geofilter Control Module 802as a result of new configuration information received from theConfiguration Post-Processing Engine 404. The result of a PopulateFunction loads a data set as input into either the Associative Module804 or the Rules Abstraction Module 806. The execution of the Populatefunction also sets the Rules Abstraction Module 806 state value(“whitelist” or “blacklist”) and also sets the default state of theNetwork Filtering Engine 412. Establishing the default state of theNetwork Filtering Engine 412 synchronizes its operation with that of theRules Abstraction Module 806. For example, a new set of RulesAbstraction Module information is loaded by a populate function, and thestate value of the Rules Abstraction Module is set to “whitelist”, orstate(x). The Populate Function further sets the default state of theNetwork Filtering Engine 412 via machine instructions transmitted fromthe Dispatch Module (808). The default state or baseline state of theNetwork filtering engine 412 is always to perform the inverse oropposite of Device Action associated with the Rules Abstraction Module'scontextual property. Hence, when the Rules Abstraction Module 806 has acontextual property of the Device Action “BLOCK”, the Network FilteringEngine 412 is set to the inverse state, “ALLOW”. Inverse states arefunctionally implemented, so that inverse relationships are internalizedby the device.

Associative Module 804 consists of one or more in memory constructscapable of performing lookup and cross-referencing on a data set basedon the operation type. A few of the operations the Associative Module804 can perform via a TRANSFORM Function are: Resource Identifier toResource Identifier, IP Address to ASN, IP Address to an ISO CountryCode, ASN number to IP Address, ASN number to IP Address, ISO CountryCode to IP Network Ranges, Net blocks, or CIDR blocks, and Country Codeto ASN numbers. Terms such as “ASN,” “ISO Country Code,” “Net blocks,”or “CIDR blocks,” where not previously defined, would be evident to oneskilled in the art.

The Rules Abstraction Module 806 is comprised of a memory structure,which internalizes the low-level constituents of the optimizedgeographic security assertions. The Rules Abstraction Module 806state-value is determined by the Configuration Post-Processing Engine404 and set by the Geofilter Control Module 802. The state-value has acorresponding Device Action Code, which is sent to the Network FilteringEngine 412 on the basis of internal logic pertaining to the ValidateFunction. The Rules Abstraction Module 06 in response to a ValidateFunction responds to the Dispatch Module 808 with either a Device ActionCode (DAC), referred to previously as the contextual property of thememory structure, or a “No Operation” (NOOP).

The Dispatch Module 808 functions so to output the result of theGeographic Filtering Engine 408 operations to the Network FilteringEngine 412 and related functional components. Output to the NetworkFiltering Engine 412 may involve transmitting a DAC or NOOP based on aVALIDATION Function. Output to the Transcoding-Output Engine 414 mayconsist of geographic relationships used during the processing ofsecurity assertions or other diagnostic or operational informationrelated to the function of the Geographic Filtering Engine 408. Outputto the Geofilter Control Module 802 may consist of return valuesindicating the need for recursion, or values indicating the completionof either a Populate or Transform function.

FIG. 9, The NETWORK FILTERING ENGINE 412 comprised by a Packet FilterModule 1002, a Logger Module 1006 and a Responder Module 1004.

The Packet Filter Module 1002 performs an action upon the incoming datapacket as determined by the Rules Abstraction Module 806 DAC associatedwith the packet. The Packet Filter Module 1002 default state isestablished by a Populate Function via the Geographic Filtering Engine408. This default state constitutes the action performed on every datapacket received by the Geographic Filtering Engine 408, unlessoverridden or trumped by the DAC received from the Geographic FilteringEngine 408. The default state of the Packet Filter Module 1002 is alwaysthe inverse of the state-value of the Assertion Abstraction Module, butthe Packet Filter Module 1002 changes in accordance with any DACreceived as a result of a Validate Function, as executed by theGeographic Filtering Engine 408.

The Responder Module 1004 responds to a datagram in a number of ways andmay operate in parallel or in the place of the Packet Filter Module1002, depending upon device coordination. A few of the possible actionsare listed below. Note, any action that can be carried out by theResponder Module 1004 has a corresponding DAC, and an inverse value asdefined by internal device logic or by a operational parameters thathave been established by the user. Example responses are listed below,wherein executing a DAC results in: blocking a particular piece ofnetwork information, such that, it is not transmitted by the system toany other network node; allowing a particular unit of networkinformation to traverse the network, in accordance, with its intendeddestination; redirecting the network information to a user-specifiednetwork, network node or subnet; logging the network information or asubset of the information, including the response by the device andother related information; or, sending network information to a networknode.

The Logger Module 1006 performs additional logging as related to theNetwork Filtering Engine 412 function. Other components may generatelogs, as well, but the Logger Module 1006 provides an additional loggingmechanism, when needed.

FIG. 10, A TRANSCODING-OUTPUT ENGINE 414 is comprised by an OutputParser Module 1008, which receives input from the Network FilteringEngine 412 Responder Module 1004, and the Network Filtering Engine 412Logger Module 1006, and an Output Feed Module 1002, which sendsinformation to the Reporting Engine Input Parser Module 1104.

The Output Parser Module 1008 determines the type of log to generatebased on the type of information received from the Network FilteringEngine 412. Once the information has been processed, it is madeavailable to the Output Feed Module 1102, which formats the output tothe Reporting Engine 416 and, other additional sources, such asoperating system components or devices. Many logging formats aresupported, and the information is converted into an appropriate formatfor the desired logging modality prior to transmission to the ReportingEngine 416 by the Output Feed Module 1102. Some of the supported loggingformats are listed below:

Generic: Proprietary format specifically designed to house output. Oneexample of this might be to format the output parser results in aproprietary protocol format.

Filesystem: Write files to the filesystem rather than, or along with,sending the information to the Reporting Module 416.

Remote (e.g. tcp, udp, http): Connect to a remote system and transmitthe logged information using a standard protocol.

Syslog, SNMP: Write the logging information to Syslog or generate SNMPinformation, based on the configuration of the devices involved.

It should be evident to one skilled in the art that other loggingformats and modalities may be implanted by the Output Parser Module 1008without departing from the scope of the present invention.

FIG. 11, A REPORTING ENGINE (107) comprised by an Input Parser (107-A),which parses the input type from the Transcoding-Parsing Engine 410 andformats this input according to the reporting, logging preferences. AnOutput Coordinator (107-B) that determines the output channel through,which received input should be sent, and whether or not the input shouldbe propagated to the UI Module, as well as, where and how the inputshould be stored. The Output Coordinator also initiates remote contactother systems and servers during the reporting process when networkcommunications are necessary for the reporting functions of the UserInterface (107-D) or involved in the storage and retrieval ofinformation. The Storage Module (107-C) contains information that hasbeen persistently stored by the geographic filter, with such storageusually involving storage within a database or file-system. The StorageModule (107-C) as such, is a computer readable medium capable ofwarehousing the data generated by the geographic filter devices. TheUser Interface Module 1210 allows the user to interact with the deviceand view its operation and alter, change, and set, configuration values.The medium through which this interaction occurs may vary depending uponthe architecture.

The Reporting Engine 416 consists of a number of modules for theprocessing of input and output related to user configuration and thereporting of geographic filter operations to the user. The configurationprocess for a geographic filter requires periodic updates, however, mostof these processes are automated by the various engines and modulespreviously discussed. Configuration directives from the user via theUser Interface Module 1210 determine: the channel through which updatesoccur, when they are to occur, from which sources, the types of sources,such as remote databases via ODBC, FTP Servers, Web Servers, DNS, or viaan automated Threat Feed. The User Interface Module 1210 also exposesadditional operational parameters to the user, such parameters andvariables being configurable within the Reporting Engine. Suchparameters and variables include geographic filter device modes ofoperation, geographic filter thresholds such as those that govern thedynamic transition between whitelists and blacklists, as well as,architecturally related operational parameters concerning such things asIP address ranges of protected network objects and the type and degreeof protection conferred.

Importantly, the User Interface Module 1210 includes various interfacecomponents, such as an interactive, Graphical User Interface (GUI), aswell as, a console or command shell interface. Within the GUI componentof the User Interface Module 1210, a user can view device logs, metrics,and statistics, graphically displayed upon a World Map. One property ofthis world map is a zoom level, enabling the user to adjust theperspective of the map from among several possible perspectives,including: world perspective, continental perspective, and countryperspective, or a user-defined perspective using customized ResourceIdentifiers. Adjustments in zoom, dynamically affect the presentation ofdata within the map such that only events relevant to the visiblesurface area of the map are presented.

Changes in map perspective are context sensitive, in accordance, with auser's preference between absolute and relative context, such thatutilizing a relative context positions the focal point of the mapbeneath the users mouse cursor, following an actuation of the mouse viaa button press. When utilizing a relative context, the focal point ofthe map is positioned in the middle of the Resource Identifier currentlyselected by the user. When using an absolute or fixed perspective, themap is proportioned so that a full set of resource identifiers arealways displayed relative to a selected set. For example, selecting theresource identifier “Europe” with an absolute context attempts toposition all of “Europe,” as defined, within the users view. Statistics,metrics, and device actions are then displayed upon the map, inaccordance with the zoom level, the map perspective, and the types ofmap data chosen by the user.

The User Interface Module 1210 also allows the user to define geographicsecurity assertions within a GUI, utilizing a graphical world mapsupporting multiple zoom levels, having previously been defined, on thebasis of which the user interactively selects previously definedregions, associating one or more of these regions with a Device Action,in accordance, with a means of altering, changing, or settingconfiguration values. Additionally, other non-geographic means fordefining security assertions are provided, including manualconsole-based specification or through the use of an “Assertion Wizard”,which guides the user through the process of defining securityassertions informally.

What is claimed is:
 1. A geographic filter device transmitting on anetwork comprising: a. a first network object capable of receiving datafrom or transmitting data to a second network object; b. a userinterface engine wherein geographic rules and configuration criteria aredisplayed, a user interacts with the device, views its operation, andalters, changes, and sets configuration criteria; c. a functional inputengine wherein input types are loaded, parsed, and processed andcorrespond with the transcoding-parsing engine; d. a configurationpost-processing engine wherein a set of configuration functions relatingto input, input optimization, and communication of processedconfiguration directives; e. a transcoding-parsing engine wherein inputis received from said configuration post-processing engine to processthe run-time input media; f. a geographic filtering engine wherein allcommunication between said first network object and said second networkobject must pass through said geographic filter engine; g. a networkfiltering engine wherein a set of network functions are performed basedon the input received from said geographic filtering engine; h. atranscoding-output engine wherein input from said network filteringengine said transcoding-parsing engine is received, a set of functionsare applied to said input, and said information is sent to the reportingengine; and i. a reporting engine wherein information is received fromsaid transcoding-output engine and reports are created and sent to adestination via a network communication protocol operation.
 2. Thedevice in claim 1, wherein said functional input engine furthercomprises: a. a media interface module opens, reads, and retrieves mediainput based on the desired media type; and b. a loader module loadsmedia input into memory for processing by the transcoding-parsingengine.
 3. The device in claim 1, wherein said configurationpost-processing engine further comprises: a. a module to receive inputfrom said user interface engine; b. a module to optimize said inputwherein configuration information is converted into generic deviceinstructions; and c. a module to output said optimized input to thetranscoding-parsing engine.
 4. The device in claim 1, wherein saidtranscoding-parsing engine further comprises: a. a parser-configurationmodule receives input from said configuration post-processing engine andsets the input mode and output mode; b. a parser-input moduleinteroperates with said loader module and encodes portions of therun-time input media received based on the mode set by theparser-configuration module; and c. a parser-output module propagatesthe parsed said run-time input media to said geographic filteringengine.
 5. The device in claim 1, wherein said geographic filteringengine further comprises: a. a geofilter control module controls theapplication of logical, arithmetic, and associative functions; b. anassociative module processes information on request by the geofiltercontrol module; c. a rules abstraction module contains a compactrepresentation of security assertions in the form of low-levelconstituents; and d. a dispatch module reports the result of geographicfiltering engine to the network filtering engine.
 6. The device in claim1, wherein said network filtering engine further comprises a respondermodule responding to a datagram.
 7. The device in claim 1, wherein saidnetwork filtering engine further comprises a packet filter moduleperforming an action upon the incoming data packet as determined by therules abstraction module.
 8. The device in claim 7, wherein said networkfiltering engine further comprises a responder module responding to adatagram.
 9. The device in claim 8, wherein said responder moduleoperates in parallel with said packet filter module.
 10. The device inclaim 6, wherein said responder module responds to the datagram by: a.blocking a particular piece of network information; b. allowing aparticular unit of network information to traverse the network with itsintended destination; c. redirecting the network information to auser-specified network, network node or subnet; d. logging the networkinformation or a subset of the information; or e. sending networkinformation to a network node.
 11. The device in claim 1, wherein saidnetwork filtering engine further comprises a logger module generatinglogs.
 12. The device in claim 1, wherein said transcoding-output enginefurther comprises: a. an output parser module receives input from saidnetwork filtering engine and generates a log function; and b. an outputfeed module formats information derived from said log function and saidinformation is sent to the reporting engine.
 13. The device in claim 1,wherein said reporting engine further comprises: a. an input parserwherein input data is formatted; b. an output coordinator whereinformatted input data received from said input parser is sent based onconfigurations in said user interface engine and includes the followingfunctions: determining the output channel to send said formatted inputdata; determining to propagate said formatted input data to said userinterface module; determining where and how said formatted input data isstored; and initiating remote contact among other systems and serversduring the reporting process when network communications are necessaryfor the reporting functions, storage of data, or retrieval of data; c. astorage module wherein data generated by said geographic filteringengine is stored; and d. a user interface module wherein deviceconfiguration criteria and geographic filter operations are displayed toa user and a user interacts with the device.
 14. The device in claim 13,wherein said storage module is a computer readable medium capable ofwarehousing data.
 15. The device in claim 13, wherein said userinterface module displays device operation and a user can alter, changeand set configuration values and criteria.
 16. The device in claim 15,wherein said configuration values and criteria comprises: a. channelthrough which updates to the device occur; b. when the updates to thedevice occur; c. source of updates to the device; or d. types of sourcesthat update the device.
 17. The device in claim 16, wherein said typesof sources is an automated threat feed.
 18. The device in claim 15,wherein said configuration values and criteria comprises IP addressranges of protected network objects.
 19. The device in claim 15, whereinsaid configuration values and criteria comprises geographic filterthresholds.
 20. The device in claim 19, wherein said geographic filterthresholds comprises a dynamic transition between whitelists andblacklists.
 21. The device in claim 13, wherein said user interfacemodule comprises an interactive graphical user interface (GUI).
 22. Thedevice in claim 20, wherein said interactive GUI is a geographic map.23. The device in claim 22, wherein said geographic map comprises a zoomin and zoom out feature on geographic perspectives.
 24. The device inclaim 23, wherein said geographic perspectives is a world map withcontinent borders.
 25. The device in claim 23, wherein said geographicperspectives is world map with country borders.
 26. The device in claim23, wherein said geographic perspectives is an user-defined perspectiveusing customized resource identifiers.
 27. The device in claim 1,wherein said destination is a network node.
 28. The device in claim 1,wherein said reporting engine formats reports in a generic format asdetermined by operational parameters and writes files to a local filesystem.
 29. The device in claim 1, wherein said reporting engine formatsreports in a generic format as determined by operational parameters andwrites files to a remote file system.
 30. The device in claim 29,wherein said remote file system is a threat feed.
 31. The device inclaim 29, wherein said remote file system is an automated threat feed.32. The device in claim 1, wherein said network communication protocoloperation comprises an open database connectivity operation.